這篇內文部分會跟我四、五年前寫過的有點像，但不寫一下好像跟後面接不起來，我就帶一下就好。

當初剛轉職成網頁設計師時，工作內容有包含政府標案，
標案有規定要通過無障礙規範，而且標案也通常都很趕，
所以都抱持著「得過且過」的心態做事，
Freego 跑下去，有錯誤就針對該項錯誤去改，
不知道的就看官方提供的範例或是 Stack Overflow找答案(快要成為時代的眼淚了)

「阿是能有多難？」 當初就是這麼天真的看待網頁無障礙

隨著時間的推移，無障礙的規範也越來越完善，我開始感受到壓力，
轉向求助有做好無障礙的 CSS 框架，祈求能減少 Debug 的時間，
但實作了一陣子，這些 CSS 框架通常是國外製作的，跟 Freego 的掃描會有點出入，
因改寫會有維護困難，果斷放棄，轉為決定自行開發。
(這段完整心路歷程可參考 之前參賽寫的比較詳細 )

當時公司的團隊成員也有意思發展看看，就開始一起了解無障礙網頁，一起刻了 CSS 框架。
不過隨著團隊成員的異動、臺灣的規範也跟上國際、使用的前端框架改版、嘗試不同的前端框架、IE 退場、歐盟推行法令讓國際知名的 CSS 框架也幾乎都支援無障礙、維護開源等種種因素，
我也逐漸了解要維護 CSS 框架、無障礙團隊持續輸出有多不容易，這曾經讓我心灰意冷。

沉寂一段時間後，我發現我還是喜歡做無障礙，我想要深耕在這一塊，
我開始思索與拆解「推廣無障礙還能有什麼樣的方式」這件事，
思考了很久，我的總結是「讓網站障礙更容易被發現，也更容易被回報與處理」。

於是帶著這樣的信念，我開始嘗試各種不一樣的工具，在其中獲取靈感，這也是為什麼三年前我要去嘗試 No-Code/Low-Code的原因，
另外就是把整個維護旅程全部解析與閉環，總結出一個屬於我的生態體系概念，
直到 LLM 開始實用後，我總算是靠著 AI 落實概念了。
本次參賽主要分享這中間的轉折與落實過程，我不確定我寫的這些文章能否有幫助到人，但至少可以記錄下我的過往，以便之後再回頭檢視。